Subject: Re: Threads
References:
X-Homemail: mailto:efp90@nuke.dircon.co.uk
X-Url: http://www.users.dircon.co.uk/~nuke/
Resent-Message-Id: <"GcF1Q1.0.9c3.N1Thn"@sunsite>
Resent-From: mui@sunsite.Informatik.RWTH-Aachen.DE
Reply-To: mui@sunsite.Informatik.RWTH-Aachen.DE
X-Mailing-List: archive/latest/1437
X-Loop: mui@sunsite.informatik.rwth-aachen.de
Precedence: list
Resent-Sender: mui-request@sunsite.Informatik.RWTH-Aachen.DE
X-Lines: 38
Status: RO
Content-Type: text/plain
Content-Length: 1507
Hi Adrian,
> could someone explain how can MUI be used by application with
> multiple threads. So far I know that one way is to have only one
> thread talking to directly to MUI and other must use PushMethod
> (which has its limitations). But I have two questions:
> 1. Is it possible to create multiple MUI application object (one
> for each thread) ?
Yes, MetaTool is one example; the only drawback is that you can't
use drag-and-drop etc. (at least not easily); for this reason my next
program will use threads so offload sub-tasks rather than whole
windows.
> 2. Can the MUI Library pointer be shared ?
Generally it's not a good idea to share any library base but... I've
found it can... however I DO open muimaster.library from every
task, I just share the pointer... maybe this isn't the same!
> 3. The Amiga OS is multithread-safe (and so is BOOPSI ?). Why MUI
> is not ?
Errm, to do with RastPort's etc.? Only one task must render into
an RP at a time... to make MUI fully Thread-Safe is do-able but would
probably damage performance for all but the few applications which
use it.
Most other windowing systems aren't TS either; NeXTStep has
extensive lightweight thread support but it's Objective-C
system is not thread-safe by default; you can turn it on but
it slows everything down by as much as 75% (NeXT figure),
although Amiga Semaphores are considerably more efficient
than NeXT/mach mutexes a bit of better design work would
normally remove the need to do this altogether.
Ellis.
Subject: PushMethod crash
To: mui@sunsite.Informatik.RWTH-Aachen.DE
Resent-Message-Id: <"wzvoU2.0.Il2.vTcin"@sunsite>
Resent-From: mui@sunsite.Informatik.RWTH-Aachen.DE
X-Mailing-List: archive/latest/1470
X-Loop: mui@sunsite.informatik.rwth-aachen.de
Precedence: list
Resent-Sender: mui-request@sunsite.Informatik.RWTH-Aachen.DE
X-Lines: 90
Status: RO
Content-Type: text/plain; charset="ISO-8859-1"
Content-Length: 2511
Hi!
In my project, I use several sub-processes that are dynamically
created and disposed. I create my ApplicationObject in the main
process, and that's also where I handle MUI's events (via standard
loop). Main process runs with a priority of 0, sub-processes are at
-1.
I know that it is not possible to access MUI from different
processes the same time, but I did it till yesterday for testing. It
worked until more than one process was running. Okay, but I got my
windows opened. Then I started to rewrite these functions with
PushMethod, and my Amiga gurued. Why?
I do something like this:
------- snip! -------
APTR GlobalApp;
subtask_func()
{
ULONG Abort_Sortin;
APTR BT_SortinCancel;
APTR WI_Sortin;
/* ... here I create WI_Sortin, BT_SortinCancel, and
much more ... */
Printf("Let's go!\n"); Delay(50);
if(WI_Sortin)
{
DoMethod(GlobalApp, MUIM_Application_PushMethod,
BT_SortinCancel, 8,
MUIM_Notify, MUIA_Pressed, FALSE,
MUIV_Notify_Self,
3,
MUIM_WriteLong, TRUE, &Abort_Sortin
);
Printf("Notification set up...\n"); Delay(50);
DoMethod(GlobalApp, MUIM_Application_PushMethod,
GlobalApp, 2,
OM_ADDMEMBER, WI_Sortin
);
Printf("Member added...\n"); Delay(50);
/* ... and so on ... */
}
}
main()
{
...
/* (standard loop) */
...
}
------- snap! -------
When I run this, I see the "Let's go", and then the sub-process
crashes with a 80000004 - Illegal Instruction. Why? WI_Sortin was
correctly initialized.
Before I changed the DoMethod() to ...PushMethod, it worked. I will
make this a custom class, but why does it crash? Subtask demo of MUI
3.3 seems to do it the same way:
343 DoMethod(data->app,MUIM_Application_PushMethod,data->self,2,
MUIM_Class4_Update,100*(y+1)/FRACTALHEIGHT);
So what's the difference?
The next thing: I think that I can't use get() and set() no more
from within my sub-processes. Is it correct to use these:
#define pset(obj,attr,val) DoMethod(GlobalApp, \
MUIM_Application_PushMethod, obj, 3, MUIM_Set, attr, val)
#define pget(obj,attr,ptr) DoMethod(GlobalApp, \
MUIM_Application_PushMethod, obj, 3, OM_GET, attr, ptr)
? And: How can I wait until the method was executed by the main
process (I have to know when *ptr will contain the value)?
Ciao,
/Johnny/ from Cologne
--
Subject: Re: PushMethod crash
From: Thomas Ganter
To: j.tevessen@line.org
Date: Tue, 4 Jun 1996 12:37:40 +0200
Cc: mui@sunsite.Informatik.RWTH-Aachen.de (MUI Mailinglist)
In-Reply-To: from "Johnny Tevessen" at Jun 2, 96 10:00:06 pm
X-Mailer: ELM [version 2.4 PL25 ME8]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Message-Id: <96Jun4.123750met_dst.4892@sunbulirsch5.mathematik.tu-muenchen.de>
Resent-Message-ID: <"pyZfV3.0.kq5.23Njn"@susi>
Resent-From: mui@sunsite.Informatik.RWTH-Aachen.de
Reply-To: mui@sunsite.Informatik.RWTH-Aachen.de
X-Mailing-List: archive/latest/1482
X-Loop: mui@sunsite.informatik.rwth-aachen.de
Precedence: list
Resent-Sender: mui-request@sunsite.Informatik.RWTH-Aachen.de
X-Lines: 54
Status: RO
Content-Type: text/plain; charset="US-ASCII"
Content-Length: 2257
[ Citation of Johnny Tevessen ]
> Hi!
>
> [... answered in previous message ...]
>
> The next thing: I think that I can't use get() and set() no more
> from within my sub-processes. Is it correct to use these:
>
> #define pset(obj,attr,val) DoMethod(GlobalApp, \
> MUIM_Application_PushMethod, obj, 3, MUIM_Set, attr, val)
> #define pget(obj,attr,ptr) DoMethod(GlobalApp, \
> MUIM_Application_PushMethod, obj, 3, OM_GET, attr, ptr)
>
> ? And: How can I wait until the method was executed by the main
> process (I have to know when *ptr will contain the value)?
Both of the above would work, but you are right, you have no
indication when the Method will have been invoked by MUI
in the other TASK's context.
And again, subclassing provides a solution. Simply write your
own class (i.e. a sublass of application) and implement your
own APPM_PushAndWait-method that could be invoked like the
standard MUIM_Application_PushMethod.
The, write your own APPM_PushAndWait to enqueue your Push-request and
the current Task in a private list in your class'es custom data structure,
then Wait() for some signal (perhaps CTRL-F, so that you can shut down
your process in case of a bug).
In your subclass'es dispatcher, simply check your private
Push-list first. Process those first and then signal the Tasks with
your magic Signal (you could of course also allocate a signalBit
each time and enqueue it along with the Task and Method Data),
dequeue the Pushed method afterwards. In case of a empty queue,
process incomming methods by passing them to superclass (excluding
APPM_PushAndWait of course :)).
I hope this helps.
--
- Thomas